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The autonomous power state section implies that a non-operational state is exited on an I/O 
Submission Queue Doorbell write only when entered autonomously. This errata clarifies that an 
I/O Submission Queue Doorbell write causes an exit from an autonomous power state regardless 
of how it was entered. 

Updated the “Number of Dwords in MPTR” to “Number of Dwords in Metadata Transfer” to be 
precise that the field in Figure 13 conveys the number of Dwords in the metadata transfer pointed 
to by MPTR. 

Updated uses of “weighted round robin with urgent priority class” to be consistent in the 
specification. 

Removed notes from the Admin opcode table that were not required and where one had become 
out of date with a feature added in NVMe 1.1. 

The Format NVM command is updated to show that the Metadata Settings field is not applicable if 
there is no metadata. The error to flag incorrect transfer settings for the metadata when there is a 
size of Oh is also removed. 

The use of the Expected Logical Block Reference Tag (EILBRT) for reads was clarified in the end- 
to-end data protection section. 

The erratum clarifies that no user data is returned for an affected namespace after a Format NVM 
command successfully completes. 

An informative section on host software recommendations for dealing with asynchronous events 
(especially persistent conditions) has been added. 

Included simplification for the Data Pointer in NVM Command Set commands. 

Various editorial corrections are also made. 



Description of the specification technical flaw: 

Modify the existing section 8.4.1 as shown below (note 8.4.1 is renumbered 8.4.2): 

The controller may support autonomous power state transitions, as indicated in the Identify Controller data 
structure in Figure 82. Autonomous power state transitions provide a mechanism for the host to configure the 
device to automatically transition between power states on certain conditions without software intervention. 

The entry condition to transition to the Idle Transition Power State is that the controller has been in idle for a 
continuous period of time exceeding the Idle Time Prior to Transition time specified. The controller is idle 
when there are no commands outstanding to any I/O Submission Queue. The power state to transition to 
shall be a non-operational power state (a non-operational power state may autonomously transition to another 
non-operational power state). Refer to section 8.4.1 for more details. I n a non - op e rat i ona l pow e r stat e , no I /O 
commands ar e proc e ss e d by th e contro lle r. 

Fo ll ow i ng an autonomous pow e r stat e trans i t i on to a non - op e rat i ona l stat e , th e contro lle r sha ll autonomous l y 

trans i t i on back to th e l ast op e rat i ona l pow e r stat e wh e n an I /O Subm i ss i on Qu e u e Ta il Doorb ell i s wr i tt e n. 

S e rv i c i ng a m e mory - mapp e d I /O (MM I O) or conf i gurat i on r e g i st e r acc e ss may caus e th e contro lle r pow e r to 

e xc ee d that adv e rt i s e d by th e non - op e rat i ona l pow e r stat e wh ile th e acc e ss i s b ei ng s e rv i c e d, how e v e r, th e 

contro lle r sha ll l og i ca ll y r e ma i n i n th e non - op e rat i ona l pow e r stat e . Proc e ss i ng a command subm i tt e d to th e 

Adm i n Subm i ss i on Qu e u e may a l so caus e th e contro lle r pow e r to e xc ee d that adv e rt i s e d by th e non - 

op e rat i ona l pow e r stat e wh ile th e command i s proc e ss e d, how e v e r, th e contro lle r sha ll l og i ca ll y r e ma i n i n th e 

curr e nt pow e r stat e un le ss th e r e i s an e xp li c i t pow e r stat e trans i t i on r e qu e st e d by a S e t F e atur e s command 

w i th th e Pow e r Manag e m e nt f e atur e i d e nt i f ie r. Wh e n s e rv i c i ng a r e g i st e r acc e ss or an Adm i n command, th e 

contro lle r sha ll not e xc ee d th e max i mum pow e r adv e rt i s e d for th e l ast op e rat i ona l pow e r stat e . 


Modify Figure 13 and the paragraph preceding the figure as shown below: 

In addition to the fields commonly defined for all Admin and NVM commands, Admin and NVM Vendor 
Specific commands may support the Number of Dwords in Data Transfer and Number of Dwords in MPTR 
Metadata Transfer fields. If supported, the command format for the Admin Vendor Specific Command and 
NVM Vendor Specific Commands are defined in Figure 13. For more details, refer to section 8.7. 















Figure 13: Command Format - Admin and NVM Vendor Specific Commands (Optional) 


Bytes 

Description 

63:60 

Command Dword 15 (CDW15): This field is command specific Dword 15. 

59:56 

Command Dword 14 (CDW14): This field is command specific Dword 14. 

55:52 

Command Dword 13 (CDW13): This field is command specific Dword 13. 

51:48 

Command Dword 12 (CDW12): This field is command specific Dword 12. 

47:44 

Number of Dwords in MPTR Metadata Transfer (NDM): This field indicates the number of 
Dwords in the metadata transfer. 

43:40 

Number of Dwords in Data Transfer (NDT): This field indicates the number of Dwords in the 
data transfer. 

39:16 

Refer to Figure 11 for the definition of these fields if it is an Admin command. Refer to Figure 12 
for the definition of these fields if it is an NVM or NVM Vendor Specific command. 

15:08 

Reserved 

07:04 

Namespace Identifier (NSID): This field indicates the namespace ID that this command applies 
to. If the namespace ID is not used for the command, then this field shall be cleared to Oh. If a 
command shall be applied to all namespaces on the device, then this field shall be set to 
FFFFFFFFh. 

The behavior of a controller in response to an inactive namespace ID for a vendor specific 
command is vendor specific. Specifying an invalid namespace ID in a command that uses the 
namespace ID shall cause the controller to abort the command with status Invalid Namespace or 
Format. 

03:00 

Command Dword 0 (CDW0): This field is common to all commands and is defined in Figure 10. 


Modify the fourth paragraph of section 4.8.2 as shown below: 

The lowest strict priority class is the W ei gh e d Weighted Round Robin class. This class consists of the three 
weighted round robin priority levels (High, Medium, and Low) that share the remaining bandwidth using 
weighted round robin arbitration. Host software controls the weights for the High, Medium, and Low service 
classes via Set Features. Round robin is used to arbitrate within multiple Submission Queues assigned to the 
same weighted round robin level. The number of candidate commands that may start processing from each 
Submission Queue per round is either the Arbitration Burst setting or the remaining weighted round robin 
credits, whichever is smaller. 


Modify the definition of arbitration burst in section 1.6.2 as shown below: 

The maximum number of commands that may be launched at one time from a Submission Queue that is 
using round robin or weighted round robin with urgent priority class arbitration. 

Modify the Arbitration Mechanism Supported field in section 3.1.1 in the Controller Capabilities 
register as shown below: 


Arbitration Mechanism Supported (AMS): This field is bit significant and indicates 
the optional arbitration mechanisms supported by the controller. If a bit is set to ‘1’, 
then the corresponding arbitration mechanism is supported by the controller. Refer to 
section Error! Reference source not found, for arbitration details. 


18:17 


RO 


Impl 

Spec 


Bit 

Definition 

17 

Weighted Round Robin with 
Urgent Priority Class 

18 

Vendor Specific 


The round robin arbitration mechanism is not listed since all controllers shall support 
this arbitration mechanism. 



























Modify the Arbitration Mechanism Selected field in section 3.1.5 in the Controller Configuration 
register as shown below: 


Arbitration Mechanism Selected (AMS): This field selects the arbitration 
mechanism to be used. This value shall only be changed when EN is cleared to 
‘O’. Host software shall only set this field to supported arbitration mechanisms 
indicated in CAP.AMS. If this field is set to an unsupported value, the behavior 
is undefined. 


Value 

Definition 

000b 

Round Robin 

001b 

Weighted Round Robin with 
Urgent Priority Class 

010b- 110b 

Reserved 

111b 

Vendor Specific 


Modify the Queue Priority field in Figure 53 as shown below: 


Queue Priority (QPRIO): This field indicates the priority s e rvic e class to use for commands within 
this Submission Queue. This field is only used when the weighted round robin with an urgent 
priority s e rvic e class is the arbitration mechanism is selected, the field is ignored if weighted round 
robin with an urgent priority s e rv i c e class is not used. Refer to section Error! Reference source 
not found.. 


02:01 


Value 

Definition 

00b 

Urgent 

01b 

High 

10b 

Medium 

11b 

Low 



























Update Figure 38 as shown below: 


Figure 38: Opcodes for Admin Commands 


Opcode 

(07) 

Opcode 

(06:02) 

Opcode 
(01:00) 

2 

Opcode 

O/M 1 

Namespace 

Identifier 

Used 3 

Command 

Generic 

Command 

Function 

Data 

Transfer 

Ob 

000 00b 

00b 

OOh 

M 

No 

Delete I/O Submission Queue 

Ob 

000 00b 

01b 

01 h 

M 

No 

Create I/O Submission Queue 

Ob 

000 00b 

10b 

02h 

M 

Yes 

Get Loa Paae 

Ob 

000 01b 

00b 

04h 

M 

No 

Delete I/O Comoletion Queue 

Ob 

000 01b 

01b 

05h 

M 

No 

Create I/O Comoletion Queue 

Ob 

000 01b 

10b 

06h 

M 

Yes 

Identify 

Ob 

000 10b 

00b 

08h 

M 

No 

Abort 

Ob 

000 10b 

01b 

09h 

M 

Yes 

Set Features 

Ob 

000 10b 

10b 

OAh 

M 

Yes 

Get Features 

Ob 

000 11b 

00b 

OCh 

M 

No 

Asynchronous Event Reauest 

Ob 

001 00b 

00b 

10h 

O 

No 

Firmware Activate 

Ob 

001 00b 

01b 

11 h 

O 

No 

Firmware Image Download 


I/O Command Set Specific 

1b 

na | na | 80h - BFh | O | | I/O Command Set specific 


Vendor Specific 

1b 

na 

na 

COh - FFh 

O 


Vendor specific 

NOTES: 

1. O/M definition: 0 = Optional, M = Mandatory. 

2. Opcodes not listed are reserved. 

3. A subset of commands uses the Namespace Identifier field (CDW1 .NSID). When not used, the field shall be 
cleared to Oh. For the Get Features and Set Features command, refer to section 7.7 for details on how the 
Namespace Identifier is used. For the Identify command, the Namespace Identifier is only used for the 

Namespace data structure. For the Get Log Page command, a value of FFFFFFFFh is used to specify that the 

global values should be returned. 


Modify Figure 39 as shown below: 


Figure 39: Opcodes for Admin Commands - NVM Command Set Specific 


Opcode 

(07) 

Opcode 

(06:02) 

Opcode 
(01:00) 

2 

Opcode 

O/M 1 

Namespace 

Identifier 

Command 

Generic 

Command 

Function 

Data 

Transfer 

Used 3 

1b 

000 00b 

00b 

80h 

O 

Yes 

Format NVM 

1b 

000 00b 

01b 

81 h 

0 

Yes 

Security Send 

1b 

000 00b 

10b 

82h 

0 

Yes 

Security Receive 


NOTES: 

1. O/M definition: O = Optional, M = Mandatory. 

2. Opcodes not listed are reserved. 

3. A subset of commands uses the Namespace Identifier field (CDW1 .NSID). When not used, the field shall be 
cleared to Oh. 































































Modify byte 26 in Figure 84 as shown below: 




Formatted LBA Size (FLBAS): This field indicates the LBA data size & metadata size 
combination that the namespace has been formatted with. 



Bits 7:5 are reserved. 

26 

M 

Bit 4 if set to T indicates that the metadata is transferred at the end of the data LBA, creating 
an extended data LBA. Bit 4 if cleared to ‘0’ indicates that all of the metadata for a command 
is transferred as a separate contiguous buffer of data. Bit 4 is not applicable when there is no 
metadata. 



Bits 3:0 indicates one of the 16 supported combinations indicated in this data structure. This 
is a 0’s based value. 


Modify bits 15:00 of Figure 85 as shown below: 


Metadata Size (MS): This field indicates the number of metadata bytes provided per LBA based 
on the LBA Data Size indicated. If there is no metadata supported, then this field shall be cleared 
to OOh. 

If metadata is supported, then the The namespace may support the metadata being transferred 
as part of an extended data LBA or as part of a separate contiguous buffer. If end-to-end data 
protection is enabled, then the first eight bytes or last eight bytes of the metadata is the protection 
information. 


Modify the Metadata Settings field in Figure 111 as shown below: 


Metadata Settings (MS): This field is set to T if the metadata is transferred as part of an extended 
data LBA. This field is cleared to ‘0’ if the metadata is transferred as part of a separate buffer. 
The metadata may include protection information, based on the Protection Information (PI) field. 
If the Metadata Size for the LBA Format selected is Oh, then this field is not applicable. _ 


Modify Figure 112 as shown below: 


Figure 112: Format NVM - Command Specific Status Values 


Value 

Description 

Ah 

Invalid Format: The format specified is invalid. This may be due to various conditions, including: 

1) specifying an invalid LBA Format number, or 

2) enabling protection information when there is not sufficient metadata per LBA, or 

supported as part of the format selected, or 

4) invalid security state (refer to TCG SIIS), etc. 


Modify bits 39:24 of Figure 12 as shown below: 














Data Pointer (DPTR): This field specifies the data used in the command. 


If CDW0[15] is cleared to ‘O’, then the definition of this field is: 


39:32 

PRP Entry 2 (PRP2): This field contains the second PRP entry for the command or 
if the data transfer spans more than two memory pages, then this field is a PRP 
List pointer. 

31:24 

PRP Entry 1 (PRP1): This field contains the first PRP entry for the command or a 
PRP List pointer depending on the command. 


lfCDW0[15] is set to T, then the definition of this field is: 


SGL Entry 1 (SGL1): This field contains the first SGL segment for the command. If 
the SGL segment is a Data Block descriptor, then it describes the entire data 
transfer. If more than one SGL segment is needed to describe the data transfer, 
then the first SGL segment is a Segment, or Last Segment descriptor. Refer to 
section Error! Reference source not found, for the definition of SGL segments 
and descriptor types. _ 


Modify Figure 125 as shown below: 


Figure 1: Compare - Data Pointer PRP Entr ie s or SGL Entry 1 


Bit 


Description _ 

Data Pointer (DPTR): This field specifies the data to use for the compare. Refer to Figure 12 for 
the definition of this field. 


I f CDW0[15] i s c le ar e d to ‘O’, th e n th e d e f i n i t i on of th i s f ie ld i s: 


1 9 7 - 6 / l 








§3400 





I f CDW0[15] i s s e t to T, th e n th e d e f i n i t i on of th i s f ie ld i s: 


127:00 
















































Modify Figure 131 as shown below: 


Figure 131: Dataset Management - Data Pointer PRP Entr ie s or SGL Entry 1 


Bit 


Description _ 

Data Pointer (DPTR): This field specifies the data to use for the command. Refer to Figure 12 
for the definition of this field. 


I f CDW0[15] i s cl e ar e d to ‘O’, th e n th e d e f i n i t i on of th i s f iel d i s: 


127'6 / l 






§3400 





I f CDW0[15] i s s e t to ‘1’, th e n th e d e f i n i t i on of th i s f ie ld i s: 


127:00 





Modify Figure 138 as shown below: 


Figure 138: Read - Data Pointer PRP Entr ie s or SGL Entry 1 


Bit 


Description _ 

Data Pointer (DPTR): This field specifies where data should be transferred to. 
12 for the definition of this field. 


Refer to Figure 


I f CDW0[15] i s cl e ar e d to ‘O’, th e n th e d e f i n i t i on of th i s f iel d i s: 


127'6 / 1 








§3400 


where data should be transferred to. 


I f CDW0[15] i s s e t to T, th e n th e d e f i n i t i on of th i s f iel d i s: 




127:00 

indicating the location where data should be transferred to. 



























































Modify Figure 145 as shown below: 


Figure 145: Reservation Acquire - Data Pointer PRP Entr ie s or SGL Entry 1 


Bit 


Description _ 

Data Pointer (DPTR): This field specifies the location of a data buffer where data is transferred 
from. Refer to Figure 12 for the definition of this field. 


I f CDW0[15] i s cl e ar e d to ‘O’, th e n th e d e f i n i t i on of th i s f iel d i s: 


1 °7’6A 






cq-nn 





I f CDW0[15] i s s e t to T, th e n th e d e f i n i t i on of th i s f ie ld i s: 


127:00 





Modify Figure 149 as shown below: 


Figure 149: Reservation Register - Data Pointer PRP Entr ie s or SGL Entry 1 


Bit 


Description _ 

Data Pointer (DPTR): This field specifies the location of a data buffer where data is transferred 
from. Refer to Figure 12 for the definition of this field. 


I f CDW0[15] i s cl e ar e d to ‘O’, th e n th e d e f i n i t i on of th i s f ie ld i s: 


1 27'6 / l 




field shall not be a pointer to a PRP List. 






I f CDW0[15] i s s e t to T, th e n th e d e f i n i t i on of th i s f ie ld i s: 


127:00 




























































Modify Figure 152 as shown below: 


Figure 152: Reservation Release - Data Pointer PRP Entr ie s or SGL Entry 1 


Bit 


Description _ 

Data Pointer (DPTR): This field specifies the location of a data buffer where data is transferred 
from. Refer to Figure 12 for the definition of this field. 


I f CDW0[15] i s cl e ar e d to ‘O’, th e n th e d e f i n i t i on of th i s f ie ld i s: 


1 27'6 / l 




field shall not be a pointer to a PRP List. 

R?-00 





I f CDW0[15] i s s e t to T, th e n th e d e f i n i t i on of th i s f ie ld i s: 


127:00 





Modify Figure 155 as shown below: 


Figure 155: Reservation Report - Data Pointer PRP Entr ie s or SGL Entry 1 


Bit 


Description _ 

Data Pointer (DPTR): This field specifies the location of a data buffer where data is transferred 
to. Refer to Figure 12 for the definition of this field. 


I f CDW0[15] i s cl e ar e d to ‘O’, th e n th e d e f i n i t i on of th i s f ie ld i s: 


1 9 7'6 / l 








RR-00 





I f CDW0[15] i s s e t to T, th e n th e d e f i n i t i on of th i s f ie ld i s: 


127:00 






























































Modify Figure 160 as shown below: 


Figure 160: Write - Data Pointer PRP Entr ie s or SGL Entry 1 


Bit 


Description _ 

Data Pointer (DPTR): This field specifies the location of a data buffer where data is transferred 
from. Refer to Figure 12 for the definition of this field. 


I f CDW0[15] i s cl e ar e d to ‘O’, th e n th e d e f i n i t i on of th i s f ie ld i s: 


1 9 7'6 / l 






then this field includes a pointer to a PRP List. 

§3400 


of data that should be transferred from. 


I f CDW0[15] i s s e t to T, th e n th e d e f i n i t i on of th i s f ie ld i s: 




127:00 

indicating the location of data that should be transferred from. 


Update the second paragraph after Figure 181 in section 8.3 as follows: 

Checking of protection information consists of the following operations performed by the controller. If bit 2 of 
the Protection Information Check (PRCHK) field of the command is set to T, then the controller compares the 
protection information Guard field to the CRC-16 computed over the logical block data. If bit 1 of the PRCHK 
field is set to T, then the controller compares unmasked bits in the protection information Application Tag 
field to the Logical Block Application Tag (LBAT) field in the command. A bit in the protection information 
Application Tag field is masked if the corresponding bit is cleared to ‘0’ in the Logical Block Application Tag 
Mask (LBATM) field of the command. If bit 0 of the PRCHK field is set to T, then the controller compares the 
protection information Reference Tag field to the computed reference tag. The value of the computed 
reference tag for the first LBA of the command is the value contained in the Initial Logical Block Reference 
Tag (ILBRT) or Expected Initial Logical Block Reference Tag (EILBRT) field in the command, for writes and 
reads respectively. The computed reference tag is incremented for each subsequent logical block. Unlike 
DIF Type 1 protection which implicitly uses the least significant four bytes of the LBA, The controller always 
uses the ILBRT or EILBRT field and requires host software to initialize the ILBRT or EILBRT field to the least 
significant four bytes of the LBA when Type 1 protection is used. 


Modify the first paragraph of section 5.13 as shown below: 

The Format NVM command is used to low level format the NVM media. This is used when the host wants to 
change the LBA data size and/or metadata size. A low level format may destroy all data and metadata 
associated with all namespaces or only the specific namespace associated with the command (refer to the 
Format NVM Attributes field in the Identify Controller data structure). After the Format NVM command 
successfully completes, the controller shall not return any user data that was previously contained in an 
affected namespace. 


Add the following new section after section 7.6: 

7.7 Asynchronous Event Request Host Software Recommendations (Informative) 






























This section describes the recommended host software procedure for Asynchronous Event Requests. 

The host sends n Asynchronous Event Request commands (refer to section 7.6.1, step 11). When an 
Asynchronous Event Request completes (providing Event Type, Event Information, and Log Page details): 

1. Host software issues a Set Features command for the Asynchronous Event Configuration feature 
specifying to disable reporting all events that utilize the Log Page reported. Host software should wait 
for the Set Features command to complete. 

2. Host software issues a Get Log Page command requesting the Log Page reported as part of the 
Asynchronous Event Command completion. Host software should wait for the Get Log Page 
command to complete. 

3. Host software parses the returned Log Page. If the condition is not persistent, then host software 
should re-enable all asynchronous events that utilize the Log Page. If the condition is persistent, then 
host software should re-enable all asynchronous events that utilize the Log Page except for the 
one(s) reported in the Log Page. The host re-enables events by issuing a Set Features command for 
the Asynchronous Event Configuration feature. 

4. Host software should issue an Asynchronous Event Request command to the controller (restoring to 
n the number of these commands outstanding). 

5. If the condition reported was persistent, host software should continue to monitor the event (e.g., over 
temperature threshold) to determine if reporting of the event should be re-enabled. 


Modify the first paragraph of section 2.6.3 as shown below: 

This register controls the reporting of the individual errors by the controller. A masked error is not reported in 
the i n th e Header Log register (AERHL), does not updated the First Error Pointer (AERCC.FEP), and is not 
reported to the host. These bits are sticky - they are neither initialized nor modified during a hot reset or FLR. 


Modify the paragraph that precedes Figure 3 as shown below: 

Figure 3 shows an NVM subsystem that contains a single NVM Express controller and a single PCI Express 
port. Since this is a single Function PCI Express device, the NVM Express controller shall be associated with 
PCI Function 0. A controller may support multiple namespaces. The controller in F i gur e xl Figure 3 supports 
two namespaces labeled NS A and NS B. Associated with each controller namespace is a namespace ID, 
labeled as NSID 1 and NSID 2, that is used by the controller to reference a specific namespace. The 
namespace ID is distinct from the namespace itself and is the handle a host and controller use to specify a 
particular namespace in a command. The mapping of a controller’s namespace IDs to namespaces is outside 
the scope of this specification. In this example namespace ID 1 is associated with namespace A and 
namespace ID 2 is associated with namespace B. Both namespaces are private to the controller and this 
configuration supports neither multi-path I/O nor namespace sharing. 


Modify the title of Figure 4 as shown below: 


Figure 4: NVM Subsystem with Two Contro l l e r Controllers and One Port 


Modify the title of Figure 5 as shown below: 

Figure 5: NVM Subsystem with Two Contro lle r Controllers and Two Ports 


Modify the paragraph that precedes Figure 5 by inserting a comma in the first sentence, as shown 
below: 






Figure 5 illustrates an NVM Subsystem with two PCI Express ports, each with an associated controller. Both 
controllers map to PCI Function 0 of the corresponding port. Each PCI Express port in this example is 
completely independent and has its own PCI Express Fundamental Reset and reference clock input. A reset 
of a port only affects the controller associated with that port and has no impact on the other controller, shared 
namespace, or operations performed by the other controller on the shared namespace. The functional 
behavior of this example is otherwise the same as that illustrated in Figure 4. 


Modify the first paragraph of section 1.4.1 as shown below: 

This section provides an overview of multi-path I/O and namespace sharing. Multi-path I/O refers to two or 
more completely independent phys i ca l PCI Express paths between a single host and a namespace while 
namespace sharing refers to the ability for two or more hosts to access a common shared namespace using 
different NVM Express controllers. Both multi-path I/O and namespace sharing require that the NVM 
subsystem contain two or more controllers. Concurrent access to a shared namespace by two or more hosts 
requires some form of coordination between hosts. The procedure used to coordinate these hosts is outside 
the scope of this specification. 


Modify the first paragraph of section 8.8.2 as shown below: 

Prior to establishing a reservation on a namespace, a host shall become a registrant of that namespace by 
registering a reservation key. This reservation key may be used as a means of identifying the registrant 
(host), authenticating the registrant, and preempting a failed or uncooperative registrant th e r e g i strant shou l d 
th e r e g i strant fa il or b e com e uncoop e rat i v e. The value of the reservation key used by a host and the method 
used to select its value is outside the scope of this specification. 

Modify Figure 83 as shown below: 


25 Non-Operational State (NOPS): This field indicates whether the controller processes I/O 
commands in this power state. If this field is cleared to ‘O’, then the controller processes I/O 
commands in this power state. If this field is set to ‘1’, then the controller does not process I/O 
commands in this power state. Refer to section 8.4.1. _ 


Insert this new section 8.4.1 as shown below: 


8.4.1 Non-Operational Power States 

A power state may be a non-operational power state, as indicated by Non-Operational State (NOPS) field in 
Figure 83. In a non-operational power state, memory-mapped I/O (MMIO) accesses, configuration register 
accesses and Admin Queue commands are serviced. No I/O commands are processed by the controller while 
in a non-operational power state. 

When in a non-operational power state, regardless of whether autonomous power state transitions are 
enabled, the controller shall autonomously transition back to the last operational power state when an I/O 
Submission Queue Tail Doorbell is written. 

Servicing a memory-mapped I/O (MMIO) or configuration register access may cause the controller power to 
exceed that advertised by the non-operational power state while the access is being serviced, however, the 
controller shall logically remain in the non-operational power state. Processing a command submitted to the 
Admin Submission Queue may also cause the controller power to exceed that advertised by the non- 
operational power state while the command is processed, however, the controller shall logically remain in the 
current power state unless there is an explicit power state transition requested by a Set Features command 
with the Power Management feature identifier. When servicing a register access or an Admin command, the 
controller shall not exceed the maximum power advertised for the last operational power state. 
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